7.07. Уровни доверия и SSL/TLS

В РАЗРАБОТКЕНЕ ДЛЯ НОВИЧКОВНЕ ОБЯЗАТЕЛЬНО

Разработчику Инженеру

Уровни доверия и SSL/TLS

Уровни доверия:

Уровень	Применение	Пример
Высокий	Банки, государственные системы, критически важные инфраструктуры	Двухфакторная аутентификация (2FA), использование HSM-ключей для защиты секретов
Средний	Корпоративные порталы, внутренние CRM и ERP-системы	Комбинация пароля и одноразового кода по SMS или из приложения
Низкий	Блоги, форумы, публичные ресурсы с минимальными требованиями к безопасности	Аутентификация по простому паролю без дополнительных факторов

SSL / TLS – процесс шифрования трафика между клиентом и сервером. Браузер при установлении показывает значок замка и https://. Для проверки используется сертификат:

• DV (Domain Validation) – базовый (проверка домена);
• OV (Organization Validation) – проверка компании;
• EV (Extended Validation) – максимальная проверка.

Методы проверки подлинности

1. Основные методы

Метод	Как работает?	Плюсы/Минусы
Логин и пароль	Проверка учётных данных на сервере по базе данных (хешированных паролей)	Плюсы: Простота реализации и использования. Минусы: Уязвимость к подбору, фишингу, необходимость безопасного хранения.
OAuth 2.0	Пользователь аутентифицируется через стороннего провайдера (Google, Facebook и др.), приложение получает токен доступа	Плюсы: Удобство для пользователя, снижение нагрузки на разработчика. Минусы: Зависимость от внешнего провайдера, передача части контроля.
JWT (JSON Web Tokens)	Токен в формате JSON, подписанный сервером; содержит данные (например, роль, срок действия); хранится у клиента	Плюсы: Отсутствие состояния на сервере, высокая масштабируемость. Минусы: Невозможность отзыва до истечения срока (без дополнительных механизмов).
Биометрия	Идентификация по уникальным биологическим признакам: отпечаток пальца, распознавание лица (Face ID)	Плюсы: Высокая степень защиты от несанкционированного доступа. Минусы: Требует специализированного оборудования, сложности с восстановлением при изменении данных.

2. JWT и сессии – сравнение

Критерий	JWT	Сессии
Место хранения состояния	На стороне клиента (в токене)	На стороне сервера (в session store, например Redis)
Масштабируемость	Высокая — не требует общего хранилища сессий	Ниже — требует централизованного хранилища (например, Redis) для работы в кластере
Безопасность	Зависит от стойкости алгоритма подписи и секрета	Зависит от защиты session ID и надёжности серверного хранилища

Верификация подлинности включает в себя и проверку домена. К примеру, почтового домена при отправлении рассылок, которая нобходима для правильного отображения имени отправителя в рассылке, а также для исключения несанкционированных рассылок.

Электронная почта остаётся одной из самых уязвимых и активно эксплуатируемых точек входа в информационные системы. Фишинг, спуфинг, рассылка вредоносного ПО и бизнес-электронное мошенничество (BEC) часто основаны на подделке адреса отправителя. Для противодействия этим угрозам были разработаны стандартизированные механизмы проверки подлинности писем на уровне DNS и криптографии: SPF и DKIM. Они являются фундаментальными компонентами современной инфраструктуры доверия в email-коммуникациях и обязательны к внедрению для любого домена, отправляющего почту.

---

1. Sender Policy Framework (SPF)

Назначение

SPF — это механизм, позволяющий владельцу домена публиковать список авторизованных почтовых серверов, с которых разрешено отправлять письма от имени этого домена.

Принцип работы

1. Администратор домена публикует в DNS TXT-запись вида:

   v=spf1 ip4:192.0.2.0/24 ip4:198.51.100.123 include:_spf.google.com -all

   Эта запись означает: «Письма от @example.com могут быть отправлены только с IP-адресов 192.0.2.0/24, 198.51.100.123 или серверов Google Workspace».

2. При получении письма принимающий MTA (Mail Transfer Agent):

   • извлекает домен из envelope sender (обычно поле Return-Path);
   • запрашивает SPF-запись для этого домена в DNS;
   • сравнивает IP-адрес отправившего сервера с разрешёнными в записи.

3. Результат проверки может быть:

   • pass — адрес авторизован;
   • fail (-all) — явный запрет;
   • softfail (~all) — временный отказ (для отладки);
   • neutral (?all) — без указания политики.

Ограничения SPF

• Не работает при пересылке: если письмо пересылается через третью систему (например, корпоративный фильтр), envelope sender может измениться, и проверка провалится.
• Не проверяет поле From:, отображаемое пользователю. Это критически важно: злоумышленник может подделать From: ceo@yourcompany.com, даже если envelope sender — другой домен. Поэтому SPF должен использоваться вместе с DMARC, который связывает проверку с видимым адресом отправителя.

---

2. DomainKeys Identified Mail (DKIM)

Назначение

DKIM — это криптографический механизм, позволяющий подписывать письма цифровой подписью и подтверждать, что:

• письмо действительно отправлено с авторизованного сервера домена;
• содержимое письма (включая заголовки) не было изменено в пути.

Принцип работы

1. Отправляющий сервер:

   • выбирает набор заголовков для подписи (например, From, Subject, Date);
   • генерирует хэш от тела письма и выбранных заголовков;
   • подписывает хэш закрытым ключом;
   • добавляет в письмо заголовок DKIM-Signature, содержащий:
     • домен (d=);
     • селектор ключа (s=);
     • алгоритм подписи;
     • подпись.

2. Принимающий сервер:

   • извлекает из DKIM-Signature домен и селектор;
   • запрашивает в DNS TXT-запись по имени {selector}._domainkey.{domain};
   • получает открытый ключ;
   • проверяет подпись с помощью этого ключа.

Пример DNS-записи DKIM:

google._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC..."

Преимущества DKIM

• Целостность: любое изменение тела или подписанных заголовков делает подпись недействительной.
• Независимость от маршрута: работает при пересылке, так как подпись не зависит от envelope sender.
• Доверие: крупные почтовые провайдеры (Gmail, Outlook) повышают репутацию доменов с корректной DKIM-подписью.

Важные нюансы

• Подпись не шифрует письмо — она только гарантирует его неизменность и источник.
• Ключи должны регулярно ротироваться (рекомендуется раз в 3–6 месяцев).
• Не проверяет, имел ли отправитель право отправлять от имени домена — только то, что письмо прошло через систему, владеющую закрытым ключом.

---

3. SPF и DKIM в совокупности: необходимость DMARC

Ни SPF, ни DKIM по отдельности не защищают пользователя от подделки отображаемого адреса отправителя (From:). Для объединения политик и принятия решений на основе результатов SPF/DKIM используется DMARC (Domain-based Message Authentication, Reporting & Conformance).

DMARC позволяет владельцу домена:

• указать, какие механизмы (SPF, DKIM или оба) требуются для прохождения аутентификации;
• задать политику обработки писем, не прошедших проверку (none, quarantine, reject);
• получать агрегированные и детальные отчёты от почтовых провайдеров.

Пример DMARC-записи:

_dmarc.example.com. IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com"

Только при наличии всех трёх компонентов — SPF + DKIM + DMARC — достигается эффективная защита от спуфинга и фишинга.

---

4. Практические рекомендации

1. Всегда публикуйте SPF-запись для любого домена, с которого отправляется почта (включая сервисы рассылки, CRM, уведомления).
2. Настройте DKIM для всех отправляющих систем (включая сторонние — SendGrid, Mailchimp и др.).
3. Имплементируйте DMARC сначала в режиме p=none для сбора отчётов, затем переходите на quarantine и reject.
4. Не превышайте 10 DNS-запросов в SPF-записи (ограничение RFC 7208).
5. Проверяйте конфигурацию с помощью инструментов:
   • dig TXT example.com
   • MXToolbox, Google Admin Toolbox, dmarcian.

---